-
Notifications
You must be signed in to change notification settings - Fork 43
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Automatic dependency resolution. #420
Conversation
advayDev1
commented
Aug 26, 2015
@brunobowden - please do #411 first; this relies heavily on it. @ph1lb4 @roisagiv - please take a look. this should automatically handle the simple kinds of dependencies you've pointed out. While the system tests do exercise the functionality, unfortunately my own project has internal native code dependencies which I haven't automated yet (I assume I am in the minority), so I cannot test this on a complicated project. So any of you trying this out would be quite helpful. If you add The one thing I know this cannot handle yet is #419. |
I will write a separate PR for updating all our docs. I think 1-hop dependencies on a third-party JAR is one of the last things we needed to simplify to get people working quickly out-of-the-box. |
6035feb
to
3c8eb98
Compare
0067cc9
to
752931f
Compare
@brunobowden - ptal; remerged/rebased. Note that all the dependency tests are in multiProject as adding a full new system test for auto deps vs. manual deps costs us a lot in terms of runtime on Travis. I think in the end we will have 3 system tests: simple, multiProject (for all kinds of dependencies), and exhaustive (which stresses every feature we have). |
4a586cc
to
12ee972
Compare
@@ -31,6 +31,7 @@ Paste the results below, replacing existing contents. | |||
- [Error: implicit declaration of function 'JreRelease' is invalid in C99 [-Werror,-Wimplicit-function-declaration] JreRelease(this$0_)](#error-implicit-declaration-of-function-jrerelease-is-invalid-in-c99--werror-wimplicit-function-declaration-jrereleasethis0_) | |||
- [How do I disable a plugin task?](#how-do-i-disable-a-plugin-task) | |||
- [How do I setup dependencies with J2ObjC?](#how-do-i-setup-dependencies-with-j2objc) | |||
- [How do I setup a dependency to a third-party Java library?](#how-do-i-setup-a-dependency-to-a-third-party-java-library) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should dependencies be split out to their own doc? It feels like that's becoming a substantial section unto itself.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
in my next PR, i hope to make dependencies a much shorter doc :)
it should be much simpler once this goes in.
906f38c
to
02b1bf4
Compare
ptal @brunobowden - should be good to go |
if you run
|
@@ -85,6 +85,21 @@ class J2objcPlugin implements Plugin<Project> { | |||
// specified in j2objcConfig (or associated defaults in J2objcConfig). | |||
File j2objcSrcGenDir = file("${buildDir}/j2objcSrcGen") | |||
|
|||
configurations { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Add note:
// These configurations are groups of artifacts and dependencies for the plugin build
// https://docs.gradle.org/current/dsl/org.gradle.api.artifacts.Configuration.html
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done. i don't see the need to link to uniquely identifiable JavaDoc (or similar though). we could do that for any gradle api...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is something more unusual and special. I'm thinking of my own ignorance as I was reading your code. If I need to look something up, then it's highly likely that someone else will need the same. If something seems straight forward to me, then I don't bother asking to add a reference. So it's a qualitative judgement that I agree should be limited.
Also, should this have a separate compile and testCompile configurations? |
No, see my reply to you earlier. There is no way to distinguish right now. |
LGTM - great work on this. Delighted to see this up and working. |
Now I just want to see at least one person using it successfully ;) |
Dependency configuration happens in 2 phases: - Dependency conversion: This converts your compile and testCompile dependencies into equivalent j2objcTranslation and j2objcLinkage dependencies. Namely local jars are copied to j2objcTranslation, external Maven jars are converted into their 'sources' form and copied to j2objcTranslation, and projects are copied to j2objcLinkage (they don't need translation). This phase is optional and controlled by j2objcConfig.autoConfigureDeps - Dependency resolution: This phase converts j2objcTranslation and j2objcLinkage deps into actual j2objc commands. Any source jar on j2objcTranslation is added to translateSourcepaths with --build-closure. Any project on j2objcLinkage is added to translateClasspaths and has its final j2objc static library linked in to this project's objective c code. This phase always runs. If your dependencies are too complicated for the plugin to figure out in the first phase, keep autoConfigureDeps=false, and just add the appropriate projets, jars, and libraries here. Also adds system tests for both project and external Maven dependencies. issue j2objc-contrib#180; Fixes j2objc-contrib#41; Fixes j2objc-contrib#372 TESTED=yes
Aside @brunobowden ; |
Automatic dependency resolution.